Enterprise architecture framework

An enterprise architecture framework (EA framework) is a architecture framework which defines how to organize the structure and views associated with an enterprise architecture.

Contents

Overview

The three components of the enterprise architecture framework are:[2]

Because the discipline of enterprise engineering and enterprise architecture is so broad, and because enterprises can be large and complex, the models associated with the discipline also tend to be large and complex. To manage this scale and complexity, an architecture framework provides tools and methods that can bring the task into focus and allow valuable artifacts to be produced when they are most needed.

Architecture frameworks are commonly used in IT and information system governance. An organization may wish to mandate that certain models be produced before a system design can be approved. Similarly, they may wish to specify certain views be used in the documentation of procured systems – the U.S. Department of Defense stipulates that specific DoDAF views be provided by equipment suppliers for capital project above a certain value. This discussion is focused for theorical teams who will develop tools and empirical methods of quality achievements.

History

Enterprise architecture started with the Zachman Framework in 1987. Another early implementation of an Enterprise architecture framework was the "Technical Architecture Framework for Information Management" (TAFIM). The first draft of TAFIM was completed in 1991 with the TAFIM Technical Reference Model (TAFIM TRM). This technical reference model wanted to use open systems and new technologies available in the commercial market, to develop a DoD-wide application.[3] The TOGAF TRM was originally derived from the Technical Architecture Framework for Information Management (TAFIM), which in turn was derived from the IEEE model 1003.0[4] or POSIX Open System Environment: a standard "to construct an information processing system, including consumers, system integrators, application developers, system providers, and procurement agencies".[5]

In recent years, it has become apparent that a key benefit to be gained from enterprise architecture is the ability to support decision making in changing businesses. Because enterprise architecture brings together business models (e.g. process models, organizational charts, etc.) and technical models (e.g. systems architectures, data models, state diagrams, etc.) it is possible to trace the impact of organizational change on the systems, and also the business impact of changes to the systems.

As this benefit has emerged, many frameworks such as DoDAF, MODAF, or AGATE have adopted a standard meta model which defines the critical architectural elements and the dependencies between them. Applications based on these models can then query the underlying architectural information, providing a simple and strong mechanism for tracing strategies to organizational and technological impacts.

EA framework topics

Framework of building codes

Persons who have ever remodeled their home, know how important building codes, blueprints, and city or county inspections are to successfully complete the project. The architect operates within a "framework" of building codes, preparing blueprints for each phase of the project, from the structural changes to the size and layout of the rooms. Detailed drawings specify plumbing, electrical, and building construction information for the entire structure. Enterprise Architecture works in a similar manner.[6]

An architecture framework for IT affects every aspect of the enterprise. An enterprise architecture framework is similar to building codes that ensure the building is soundly constructed. The IT governance bodies and procedures serve as the city and county inspectors for building improvement projects. Frameworks contain models and standards that will be used to develop IT architecture descriptions. The architecture description is the blueprint.[6]

Architecture domain

In the context of the creation of Enterprise Architecture it is common, according to Péter Bernus (2005),[8] to recognise three or four types of architecture, each corresponding to its particular architecture domain. Examples of such domains are:

Architectural domains are a structuring criterion for a collection of architecture products. They should not be confused with the application domain of the framework as such.[8]

Layers of the enterprise architecture

Contemporary federal guidance suggests thinking about “layers” of the enterprise architecture:[9]

The Architecture Domains follow a pattern of decomposition as one goes from top to the bottom of the framework. The ownership can be divided into 4 broad categories: planner's view, owner's view, designer's view and developer's view in this order. All the views are mostly hierarchical in nature. For business view the planner and owner's level is typically called the value chains (which are descriptive by nature). The designer's view of business is also known as the analytical view and there are various standards for modeling this view. One commonly used modeling standard is the Business Process Modeling Notation (BPMN). The designer's view typically represents the execution level which uses standards like Business Process Execution Language (BPEL).

Enterprise architecture domains and subdomains

The application and technology domains (which are not to be confused with business domains) are characterized by domain capabilities and domain services. The capabilities are supported by the services. The application services are also referred to in service-oriented architecture (SOA). The technical services are typically supported by software products.

The data view starts with the data classes which can be decomposed into data subjects which can be further decomposed into data entities. The basic data model type which is most commonly used is called merda (master entity relationship diagrams assessment, see entity-relationship model). The Class, subject and entity forms a hierarchical view of data. Enterprises may have millions of instances of data entities.

The Enterprise Architecture Reference Traditional Model offers clear distinction between the architecture domains (business, information/data, application/integration and technical/infrastructure). These domains can be further divided into Sub domain disciplines. An example of the EA domain and sub domains is in the image on the right.

Many enterprise architecture teams consist of Individuals with Skills aligned with the Enterprise Architecture Domains and sub-domain disciplines. Here are some examples: enterprise business architect, enterprise documentational architect, enterprise application architect, enterprise infrastructure architect, enterprise information architect, etc.

An example of the list of reference architecture patterns in the application and information architecture domains are available at Architectural pattern (computer science).

View model

A view model is a framework, which defines the set of views or approaches to be used in systems analysis or systems design or the construction of an enterprise architecture.

Since the early 1990s there have been a number of efforts to define standard approaches for describing and analyzing system architectures. Many of the recent Enterprise Architecture frameworks have some kind of set of views defined, but these sets are not always called "view models".

Standardisation

A first important standard in the field of software architecture and system architecture is IEEE 1471, an IEEE Standard for describing the architecture of a software-intensive system approved in 2000. This standard has been adopted by the International Organization for Standardization (ISO) and published as ISO/IEC 42010:2007, still identical to the IEEE 1471:2000. In 2006 a technical committee of the ISO launched a revision of this standard, now published as ISO/IEC/IEEE 42010:2011.

ISO/IEC/IEEE 42010 establishes common terminology for architecture framework and specifies requirements for standardization of frameworks. An architecture framework is defined as:

conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders

An architecture framework is specified by:

  1. the relevant stakeholders in the domain,
  2. the types of concerns arising in that domain,
  3. architecture viewpoints framing those concerns and
  4. correspondence rules integrating those viewpoints cited before.

Frameworks conforming to the standard can include methods, tools, definitions, methods and other practices beyond those specified.

Types of enterprise architecture framework

Consortia-developed frameworks

Open-source frameworks

Enterprise architecture frameworks that are released as open source:

Proprietary frameworks

Defense industry frameworks

Government frameworks

See also

References

  1. ^ The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1. September 1999.
  2. ^ a b Stephen Marley (2003). Architectural Framework. NASA /SCI. Retrieved 10 Dec 2008.
  3. ^ Patricia A. Oberndorf and Anthony Earl (1998). Department of Veterans Affairs Reference Models. SEI Carnegie Mellon University.
  4. ^ Van Haren (2007) TOGAF 2007 Edition. ‎The Open Group. p.142.
  5. ^ Guide to the POSIX Open System Environment (OSE). General info. Accessed 12 Dec 2008.
  6. ^ a b c Rob Thomas and Phil Cullen (2001). "Building an Enterprise Architecture framework". In: US Customs Today April 2001.
  7. ^ FEA Consolidated Reference Model Document. whitehouse.gov May 2005.
  8. ^ a b Péter Bernus (2005). Knowledge Sharing in the Integrated Enterprise. p.133-139.
  9. ^ a b Niles E Hewlett (2006) , The USDA Enterprise Architecture Program. PMP CEA, Enterprise Architecture Team, USDA-OCIO. January 25, 2006.
  10. ^ L.M. Camarinha-Matos, H. Afsarmanesh, Collaborative Networks: Reference Modeling, Springer, 2008.
  11. ^ L.M. Camarinha-Matos, H. Afsarmanesh, On reference models for collaborative networked organizations, International Journal Production Research, Vol 46, Nº 9, May 2008, pp 2453–2469.
  12. ^ Tony Shan and Winnie Hua (2006). Solution Architecting Mechanism. Proceedings of the 10th IEEE International EDOC Enterprise Computing Conference (EDOC 2006), October 2006, p23-32.
  13. ^ US Department of the Treasury Chief Information Officer Council (2000). Treasury Enterprise Architecture Framework. Version 1, July 2000.